--- title: "Laudo Oficial de Correção — Prova Teórica 1" subtitle: "Gestão de Projetos de Software (GPS) • CEFET-MG 2026.2" author: "Prof. Aléssio Miranda Júnior" date: "2026-10-19" discente: "Victor Otávio Souza" matricula: "20243001219" nota_final: "17,5" nota_maxima: "25,0" aproveitamento: "70,0%" legibilidade: "94% (Alta)" format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm colorlinks: true --- ::: {.callout-note appearance="simple"} ## Dados do Discente - **Discente:** Victor Otávio Souza - **Matrícula:** `20243001219` - **Data da Avaliação:** 19/10/2026 - **Pontuação Final:** **17,5 / 25,0** (Aproveitamento: **70,0%**) - **Legibilidade da Caligrafia:** 94% (Alta) ::: ## Desempenho Consolidado por Questão | Questão / Tema | Pontos Obtidos | Valor | Aproveitamento | |:---|:---:|:---:|:---:| | **Q1:** Projeto, Ciclo de Vida e Trade-offs | **4,7** | 5,0 | 94,0% | | **Q2:** Escopo, EAP e Backlog | **1,5** | 5,0 | 30,0% | | **Q3:** Qualidade, CoQ e Definição de Pronto | **4,4** | 5,0 | 88,0% | | **Q4:** Riscos, Segurança de IA e Documentação | **3,9** | 5,0 | 78,0% | | **Q5:** Comunicação, Stakeholders e Conflitos | **3,0** | 5,0 | 60,0% | | **TOTAL GERAL** | **17,5** | **25,0** | **70,0%** | --- ## Questão 1 — Projeto, Ciclo de Vida e Trade-offs (4,7 / 5,0 pts) ### 1.1 Classificação como Projeto vs. Operação e Evidências (1,2 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "O professor é um projeto, pois tem como objetivo uma entrega final, tem um tempo determinado para isso, e após a entrega não exige acompanhamento e correções." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Classificou corretamente como Projeto . Justificou adequadamente com a temporalidade (prazo determinado) e objetivo único (entrega final). A última oração sobre "não exigir acompanhamento" contradiz a fase operacional contínua, deixando de citar restrição de recursos/custos ou elaboração progressiva. Pontuação: 1,2 / 1,5. ::: ### 1.2 Alternativas de Trade-off no Triângulo de Ferro (2,0 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Uma alternativa seria reduzir algumas funcionalidades do agente (redução de escopo) e outra seria atraso na entrega (tempo) para conseguir entregar o agente com qualidade." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente! Propôs com precisão duas alternativas clássicas sem sacrificar a qualidade: (1) redução do escopo de funcionalidades e (2) extensão do prazo/tempo de entrega. Pontuação integral: 2,0 / 2,0. ::: ### 1.3 Classificação do Ciclo de Vida (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "O ciclo de vida deve ser o ágil, pois como o agente (IA) é não determinístico e é difícil prever suas respostas, o ágil permite correções e conferências constantes, mantendo o controle do projeto." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Muito bom! Classificou como ciclo Ágil e fundamentou com maestria na natureza não-determinística da inteligência artificial, que exige entregas iterativas e inspeções constantes. Pontuação integral: 1,5 / 1,5. ::: --- ## Questão 2 — Escopo, EAP e Backlog (1,5 / 5,0 pts) ### 2.1 Estrutura Analítica do Projeto (EAP) e Regra dos 100% (0,0 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > [NÃO RESPONDEU / EM BRANCO] ::: ::: {.callout-tip icon=false title="Parecer do Docente"} O quadro reservado para o desenho da EAP e explicação da Regra dos 100% foi deixado em branco. Pontuação: 0,0 / 1,5. ::: ### 2.2 Detalhamento de Issues e Estimativa Relativa (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "• Titulo: Criação do Project Charter | Descrição: Criar um arquivo PROJECT_CHARTER.md que defina os escopos do projeto. | Criterio: [ ] criar o doc PROJECT_CHARTER.md na docs. [ ] descrição correta do documento. | Estimativa: Tempo estimado: 2h30m 2ª Issue: Criar documento CASOS_TESTE no qual registra os testes do tutor com 3 problemas (Fácil, Médio, Difícil) do juiz online e 1 caso de prompt injection. | Estimativa: 5h. * A diferença da estimativa ocorre pois ambos são sobre criar um doc, porém o segundo envolve busca de problemas, testes e o registro." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente formulação! Detalhou a Issue 1 com todos os 4 elementos canônicos (título, descrição, critérios verificáveis e estimativa) e justificou de forma brilhante o esforço relativo da Issue 2 (5h vs 2h30m) em função da complexidade empírica de teste. Pontuação integral: 1,5 / 1,5. ::: ### 2.3 Milestones vs. Sprints no Modelo Ágil / Kanban (0,0 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > [NÃO RESPONDEU / EM BRANCO] ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Subitem deixado em branco pelo discente. Pontuação: 0,0 / 2,0. ::: --- ## Questão 3 — Qualidade, CoQ e Definição de Pronto (4,4 / 5,0 pts) ### 3.1 Definição de Pronto (DoD) e Relação com CI/CD (0,9 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "O CI garante que códigos requisitados para merge sejam verificados, e em caso de não conformidades, não são aprovados. O CD é quando o código é conforme, e ele é empacotado e disponibilizado para Merge Request. Omitir esses testes pode prejudicar a integridade do projeto, deixando-o sucetível a merge de códigos que quebrem a lógica e prejudiquem o fluxo." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Compreendeu o papel dos checks automáticos no pipeline CI e concluiu com precisão que omitir os testes ameaça a integridade do sistema. Faltou formalizar explicitamente o conceito central de Definição de Pronto (DoD) como contrato compartilhado de completude da equipe. Pontuação: 0,9 / 1,5. ::: ### 3.2 Classificação PAF dos Custos da Qualidade (CoQ) (1,5 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Custo de Prevenção: (a) revisão por par | Avaliação: (b) testes automatizados | Falha Interna: (d) falha no deploy | Falha Externa: (c) bug de segurança encontrado pelo aluno [indicado como custo mais alto] * O bug de segurança é o mais caro, pois foi detectado pelo cliente, devido o conceito da 1:10:100, custo para corrigir x 100." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Perfeito! Mapeou com exatidão as quatro categorias de CoQ e justificou com clareza o motivo de (c) ser o mais crítico (descoberta pelo cliente/aluno em produção multiplicando o custo de reparo). Pontuação integral: 1,5 / 1,5. ::: ### 3.3 Heurística 1:10:100 e Particularidades de Projetos de IA (2,0 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Regra 1:10:100 -> afirma que a prevenção tem custo 1, correção em produção tem custo 10, e após a entrega tem custo 100. Ela é importante para que a equipe sempre atue com foco em qualidade, realizando teste para identificar possíveis bugs e falhas. Seus limites com IAs são: IAs não são determinísticas, então é impossível prever 100% o seu comportamento, dificultando a prevenção, mas nunca abandonando testes e simulações." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Resposta impecável! Explicou a progressão da heurística, identificou o limite intrínseco do não-determinismo em modelos de linguagem que impede a prevenção absoluta de falhas e concluiu com o uso qualitativo da regra para priorizar testes e simulações preventivas. Pontuação integral: 2,0 / 2,0. ::: --- ## Questão 4 — Riscos, Segurança de IA e Documentação (3,9 / 5,0 pts) ### 4.1 Risco vs. Problema e Posicionamento na Matriz P×I (1,2 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Inicialmente, vazamento da chave é um Risco, mas para o evento descrito (vazou a chave) ele se tornou um Problema. Classifiquei na Matriz PxI como médio, pois o Impacto do vazamento seria alto, porém a chance de acontecer é baixa devido as ferramentas e estratégias que se tem." [Matriz P×I marcada no quadrante Impacto Alto x Probabilidade Baixa]. ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Diferenciou com clareza o risco (incerteza) do problema consumado. Posicionou corretamente na Matriz P×I justificando o quadrante de alto impacto e baixa probabilidade. Faltou indicar explicitamente a denominação formal da estratégia prévia de mitigação. Pontuação: 1,2 / 1,5. ::: ### 4.2 Ações Imediatas e Prevenção Permanente de Chaves de API (1,3 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Ação preventiva -> colocar a chave no arquivo .env e adicioná-la em um arquivo git ignore, evitando que a chave seja compartilhada indevidamente. 3 ações -> interromper a aplicação, retirar a chave vazada e substituir por uma nova chave (blindar a mesma para evitar novos vazamentos)" ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Muito bom! Ação preventiva correta (.gitignore e .env). Ações imediatas incluíram revogação/troca da chave e parada do serviço exposto. Faltou citar a auditoria dos logs de chamadas para apurar custos e consumo indevido. Pontuação: 1,3 / 1,5. ::: ### 4.3 Modelagem de Riscos de IA e Artefatos de Documentação (ADRs) (1,4 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Prompt Injection (Esqueça que você é um tutor socrático) - Pode causar entrega de código pronto, a P é alta (o aluno querer um código pronto) e I é alto (pois fere o objetivo do tutor socrático), para contornar isso, deve-se aplicar uma defesa em profundidade, controlando a saída (se tem código) e retendo, devolvendo mensagens amigáveis. Documento: SYSTEM_PROMPT, pois detalha como o tutor deve se comportar." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Modelagem de risco de entrada muito competente (causa, P, I, contingência e defesa em profundidade na saída). Quanto ao artefato de documentação da decisão técnica arquitetural da equipe, indicou SYSTEM_PROMPT em vez do ADR (Architecture Decision Record) formal solicitado pela engenharia de software. Pontuação: 1,4 / 2,0. ::: --- ## Questão 5 — Comunicação, Stakeholders e Conflitos (3,0 / 5,0 pts) ### 5.1 Comunicação Síncrona vs. Assíncrona no GitLab (1,25 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "A comunição síncrona é uma comunicação ágil e de fácil acesso, porém todas as definições feitas por ela são difíceis de rastrear. Já a comunicação assíncrona é a comunicação oficial da equipe, tudo é rastreável, quem executa, o tempo de produção. O time realiza reuniões para nortear o trabalho, definir os responsáveis na produção das tarefas, porém o Git é onde tudo é oficializado, onde Issues são ou não aprovadas, os porquês, como foi executado." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Excelente distinção entre a agilidade do contato síncrono e a rastreabilidade e governança das decisões assíncronas no GitLab. Pontuação: 1,25 / 1,5. ::: ### 5.2 Matriz Poder × Interesse e Estratégia de Comunicação (1,25 / 1,5) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "② Professor da disciplina: Além de cliente, ele é quem patrocina o projeto, o que comprova sua alta importância, devendo estar ciente de tudo tendo acesso direto no Git para acompanhar as entregas e o fluxo de trabalho. ① Alunos: Os clientes finais, que tem interesse direto na ferramenta. Um canal de comunicação poderia ser calls ou chats para troca de informações." [Diagrama: (2) Gerenciar de perto; (5) Manter satisfeito; (4) Monitorar; (1) e (3) Manter informado] ::: ::: {.callout-tip icon=false title="Parecer do Docente"} Posicionou corretamente o Professor em Gerenciar de perto e definiu estratégia sólida de transparência no Git. A equipe de desenvolvimento (3) deveria figurar em Gerenciar de perto (Alto Poder/Interesse) em vez de apenas Manter informado . Pontuação: 1,25 / 1,5. ::: ### 5.3 Modos de Resolução de Conflito de Thomas-Kilmann (0,5 / 2,0) ::: {.callout-note icon=false title="Resposta Transcrita do Aluno"} > "Respostas curtas seriam interessantes pois o tutor não precisa dar a resposta, e sim guiar o aluno. Com respostas curtas seria possível levantar indagações para guiar o aluno. Inadequadas: Assinatura para tokkens ilimitados: o abuso poderia tornar a operação inviável, e outra seria trabalhar com banco de dados, com o passar do tempo ficaria sobrecarregado e prejudicaria a operação." ::: ::: {.callout-tip icon=false title="Parecer do Docente"} O discente discutiu o mérito didático das respostas curtas e sugeriu alternativas técnicas, porém não aplicou a taxonomia dos Modos de Conflito de Thomas-Kilmann (Colaborar, Conciliar, Forçar, Acomodar, Evitar) nem demonstrou por que duas abordagens formais seriam inadequadas segundo o modelo teórico solicitado. Pontuação: 0,5 / 2,0. ::: --- *Laudo gerado oficialmente pela disciplina Gestão de Projetos de Software (GPS) • CEFET-MG Timóteo*